For preserving the privacy of the of a sender information is usually encoded or encrypted before it has to be transmitted through an insecure channel, so that only the intended receiver of the information can decrypt and read it. Therefore, other people, entities or systems with access to this information are not able to read it.
Encryption can be used to protect the privacy of the sender but it not to preserve the information integrity. In fact, this information may be modified during the encryption process or the transmission, so the receiver could not receive the same information sent by the sender. Therefore, it is important to provide to the sender means for detecting modifications in the transmitted information and therefore, for verifying that the information recorded by the receiver is the same the sender sent. Digital signatures of the encrypted information can be used to ensure that the integrity of the information is preserved during transmission. However, they cannot be used to verify that the information has been properly encrypted. Therefore, the sender should have to trust the encryption process. The encryption process is usually done by specific software which is susceptible to be manipulated by an external entity with the end to modify the information before encrypting. One solution could be digitally signing the information and encrypt the information and its signature together. However, this approach compromises the privacy of the sender, since information, once decrypted, would be linked to the identity of the sender by the digital signature also obtained in the decryption process.
In scenarios where the initial receiver of the information is not the final destination, and therefore the former does not have the ability to decrypt this information, verifying that the information received by the initial receiver is the same one sent by the sender is a complex process. Several methods can be used to solve this problem.
Verifying that the Sent Information is the Same it was Intended to Send
In some schemes it is important for a sender, who sends an encoded message to a receiver entity, to be able to verify that the received encoded message contains the information encoded by the sender, without compromising neither the secrecy of the sent information (at least until this information is decoded) nor the sender anonymity. An example of such scheme is an electronic voting process, where the voter chooses her voting options, which are encoded and stored in a receiver device. The digital signature allows verifying that the information, once encoded and digitally signed (actions done before sending and/or storing it), has not been manipulated. However, the information can be manipulated during the encoding process.
When the voting options are encoded, the voter usually has to trust that the encoding process is really encoding the options she has chosen and therefore, that these options are present in the encrypted message received by the receiver entity.
Several techniques have been developed to allow the voter to verify that the encoded sent message corresponds to her voting intent. Some of these techniques make an end-to-end verification, where the receiver of the encoded message proofs to the sender that the received encrypted message contains is the same information encrypted by the sender. Other techniques focus on the verification of the encoding process.
End-to-End Verification
[Ch01] and [Ma02] describes a method for the end-to-end verification of the content of an encoded message or vote, in such a way that the receiver provides to the voter a proof proving that the received encoded vote contains the voting options selected by the voter.
This verification method is based on the generation, before the voting phase, of codes assigned to each candidate or voting option that are equivalent to the encoding of that option. A second code (known as return code) is calculated from each first code, using a cryptographic operation (for example, a Hash function) and a secret parameter.
These both code pairs are sent in voting cards to the voters. The codes are calculated in such a way that they are different for each voter, candidate and voting card.
At the time of voting, the voter selects the codes corresponding to the voting options she wants to choose, and sends them to a voting server. The voting server generates the corresponding return codes from the received voting option codes using a secret parameter only known by the server. Then, it sends the generated return codes to the voter, who checks that they match the return codes printed in her voting card assigned to the voting options she has selected.
Since the secret parameter, needed to generate the return codes, is only known by the voting server, and that these codes are not stored but calculated from the received codes, the voter can verify that the options she has chosen are related to the codes received by the server. Moreover, since the return codes are calculated from the values of the codes representing the voting options, the secrecy of the vote is preserved.
The main weakness of this method is in the protection of the voting cards. Since the candidate codes are different for each voting card and are not related with the names of the candidates, anyone who has access to the voting cards before the voting phase could exchange the codes of two candidates, shifting then the votes for one candidate to the other. Another important weakness is the usability of this system: introducing and checking alphanumeric codes increases the complexity of the voting system from the voter point of view.
Verification of the Encoding Process
In [Be06] a different idea, where the verification is focused on checking the encoding process, is presented.
After the sender has chosen the message content, this is encoded by an entity which commits to the resulting encoded message. That way, after encoded message cannot be modified. After this operation, the sender can choose between two options: send the message or, in case she wants to verify, ask to the entity that encoded the message to decode it, so the sender can check if the content of the encoded message corresponds to the selections she made. In case the verification is performed, the encoded message (which content has been disclosed) is rejected and a new encoded message is created from the same content in order to protect the sender privacy. Since the verification is a decision of the sender of the information, she can give to the encoding entity information different from his intent, in order to preserve the confidentiality if the information is decoded for the verification.
An implementation based on the system proposed in [Be06] is done in [Ad08]. Once the message has been encoded and the entity in charge of doing this encoding has committed to the result, there are two options: send the encoded message or verify the encoding process. This method differs from the previous one from the fact that, instead of doing the verification by asking to the entity in charge of encoding the message to decode it, the sender asks to the entity for releasing certain parameters used to encode for verifying in an independent way that the encoding is correct.
Another proposal based on [Be06] is [Sa08]. This proposal is specifically designed for polling places where voters cast their votes using voting machines. In the proposal, the voting machines are interconnected by means of a local network isolated from external networks, so that a message from an external network cannot access the local one.
When a voter casts a vote encoded in one of the voting machines, it is sent through the local network and stored in all the voting machines of the polling place. After this “publication” of the encoded vote in all the machines, the voter can choose between verifying if the content of the encoded vote matches her selected options or definitively cast it (although it has been already sent). In case the voter chooses to cast the encoded vote, the machine stores a record of this acceptation, since the vote has already been sent to all the machines of the polling place. Otherwise, if the voter chooses to verify that the encoded options are the same she chose, the machine publishes the information used to make the encoding through the local network.
With the intention of providing a verification method in real time, the proposal considers that the local network may be connected to an external network or Internet by means of a data diode ensuring the information only flows in one direction, so that an external observer can observe the data traffic in the local network in real time. Then, the voter or an external observer can capture the vote and the released encoding parameters in order to verify that the encoded options are those which were selected. Once a vote is audited, it is rejected in all the voting machines through the local network.
The main drawback of these methods is that the voter has to use an alternative system to verify the correct encoding of the options once the system releases the encoding parameters. The cryptographic operations needed to perform this verification cannot be done by hand or using a conventional calculator. The use of an alternative device to make these calculations may lead to verification problems and usability issues for the voter.
The described methods for the verification of the correct registration of information have an important usability problem: users have to do complex operations to perform the verification, such as the comparison of numerical or alphanumerical codes, or mathematical operations with large numbers.
The present invention is based on a method for the verification of the correct registration of information solving the usability problems of the existing methods.